Smalltalk › Instantiations

delay to resolve simultaneus requests using network socket

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

3 messages Options

SergioN

delay to resolve simultaneus requests using network socket

Hi VA-Smalltalk community!

We are working on headless application developed on VASmalltalk 8.5.2, that solves client requests opening TCP connections. The application is running on Enterprise Redhat 5.5 (64 bits) operative system.

First of all, we have a Smalltalk process that listens to new connections and accepts them. As follows:

[

…

aSciSocket := anAbtSocket accept.

self doSomethingWithSocket: aSciSocket.

…

] fork

After a new connection is established, it forks a process to carry out a reception as follows:

[

…

result := socket recvAll: aBuffer length: aLength startingAt: aPosition flags: 0.

self doSomethingWithData: result.

…

] fork

However, the application becomes slow when it receives simultaneous requests. This situation causes a delay as the data is being read. The more simultaneous requests the application receives, the slower it becomes.

I attached the results that were gathered from simultaneous requests to show how the performance decreases. It was tested using different amounts of requests.

Finally, while looking into your socket framework we found a possible cause for these delays. It could be related to how the resources (FIXED MEMORY, Threads, …) are freed.

About FIXED MEMORY: it was increased to 50MB but there were no changes.

About OS threads: we think that Linux does not fix the amount of threads created per process; because the global limit is really high (over 1.000.000).

Let me know if you have any suggestions about how to fix it.

Thanks!

Regards,

Sergio

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at http://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/groups/opt_out.

test results.xls (46K) Download Attachment

Wayne Johnston

Re: delay to resolve simultaneus requests using network socket

I don't know much about sockets/Linux/fixedMemory/threads, but how are your results different than what I would ignorantly expect given what I think your tests are trying (requests starting at the same time). That is, with few requests the throughput is limited by I/O speed. And then with many requests, is your application CPU bound? It would make sense then as you go from 50 to 100 concurrent requests, that the per-request elapsed time about doubles. I suspect you have considered this already and you are saying your application is not CPU bound and there seems to be some other limitation (bottleneck)?

Thomas Koschate-2

Re: delay to resolve simultaneus requests using network socket

In reply to this post by SergioN

On Saturday, August 10, 2013 2:03:57 AM UTC-4, Sergio Nascimbene wrote:

About OS threads: we think that Linux does not fix the amount of threads created per process; because the global limit is really high (over 1.000.000).

Perhaps you're not aware, but Smalltalk does not take advantage of OS threads. The number of threads used under Linux is three. When you create a new process via a fork in the image, it spins off a new Smalltalk process, which shares the main execution thread with all others.

As Wayne already pointed out, you may have some other bottleneck. I would say, however, that the bottleneck is likely in your programming. In a past life, I was responsible for an application that serviced thousands of TCP/IP calls per minute with database requests. It can be done in a Smalltalk image, but your code may need to be reworked to handle it properly.

You may find that it's actually better to serialize your handling using a queue, rather than just forking everything. There's a significant amount of overhead involved in creating new processes, both in terms of CPU and memory. By queueing the requests in some way, you'll greatly reduce that overhead, and actually increase the amount of CPU available to service requests.

Tom