>If so, I think that it's a waste of memory; it would imVHo be a
better idea setting up a common, shared "pool" containing all
those data and allow all the threads to access it; such a thing
All data that could be shared are shared between the threads. But there
are some data structures that could not be shared (restriction of perl).
And it is wrong to think that shared data are only holded once in the
memory. Every data (shared and unshared) are holded by every thread, but
the shared are changed in every thread via threads::shared if they are
changed in any of the threads.
Thomas
"GrayHat" <[email protected]>
02.03.2009 20:46
Bitte antworten an
GrayHat <[email protected]>; Bitte antworten an
ASSP development mailing list <[email protected]>
An
<[email protected]>
Kopie
Thema
[Assp-test] ASSP v2 2.0.0 (14.02) - test report
As for subject I downloaded the above version and
gave it a spin; the platform is:
win2k3, Intel Xeon 2.8 Ghz, 2Gb RAM
Active Perl 5.8.8; all needed modules installed (or at least
the ASSP logged an "all ok"); ASSP running as a service
Started up the ASSP, it took some seconds to startup
all the threads but started ok; had a look at the connections
page, saw that ASSP was suggesting to increase the number
of workers to 10, so changed that and restarted ASSP, then
I left it run for some hours and was happy to see that those
darn "IO poll" error didn't pop up as for previous version
but then ...
After some hours ASSP died; no error was logged and
there was no other info, perl just suddenly died; so I think
there must be some "bug" crashing the code
That said; and looking at the time the code was running,
I can say that the latest 2.0.0 seems good (aside from that
crash); there's only one thing I'd like to report
Whenever you change whatever setting on the WEB admin
GUI, each ASSP thread start reloading all the infos, so the
log shows each thread reloading the VRFY domain list and
so on; now... this seems to imply that each thread has its own
copy of the config settings... am I correct ? And does such a
thing also apply to the bayes database and to the various
lists (eg black helo, IPs and so on) ?
If so, I think that it's a waste of memory; it would imVHo be a
better idea setting up a common, shared "pool" containing all
those data and allow all the threads to access it; such a thing
would help reducing the memory fingerprint and would also
avoid reloading the same data over and over
HTH
------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco,
CA
-OSBC tackles the biggest issue in open source: Open Sourcing the
Enterprise
-Strategies to boost innovation and cut costs with open source
participation
-Receive a $600 discount off the registration fee with the source code:
SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Assp-test mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/assp-test
DISCLAIMER:
*******************************************************
This email and any files transmitted with it may be confidential, legally
privileged and protected in law and are intended solely for the use of the
individual to whom it is addressed.
This email was multiple times scanned for viruses. There should be no
known virus in this email!
*******************************************************
------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Assp-test mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/assp-test
